-
Notifications
You must be signed in to change notification settings - Fork 14k
Add rust-mingw component for *-windows-gnullvm hosts
#147536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Tested locally on Windows but a shareable build would be useful. |
This comment has been minimized.
This comment has been minimized.
Windows-gnullvm self-contained try-job: dist-x86_64-linux try-job: dist-x86_64-windows-gnullvm
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
@bors try jobs=dist-x86_64-linux,dist-x86_64-windows-gnullvm |
This comment has been minimized.
This comment has been minimized.
Windows-gnullvm self-contained try-job: dist-x86_64-linux try-job: dist-x86_64-windows-gnullvm
|
Seems to work nicely, even with |
|
@mati865 are there any blockers we could help you with? |
|
@estebank I had a few ideas how to refactor it, but none of them turned out satisfying. I'm going to take another stab at it this week. |
f3f33b7 to
9d27d77
Compare
This comment has been minimized.
This comment has been minimized.
9d27d77 to
9f92112
Compare
This comment was marked as resolved.
This comment was marked as resolved.
48d04c8 to
2b5ac0b
Compare
|
@bors try jobs=dist-x86_64-linux,dist-x86_64-windows-gnullvm |
This comment has been minimized.
This comment has been minimized.
Windows-gnullvm self-contained try-job: dist-x86_64-linux try-job: dist-x86_64-windows-gnullvm
|
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 This PR modifies If appropriate, please update These commits modify compiler targets. |
| return ret; | ||
| } | ||
|
|
||
| // When using a supported target in self-contained linker mode, we want to use rust-lld directly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dislike this at pretty fundamental level.
-Clink-self-contained isn't supposed to change the linker flavor, only to change where the linker (and other things) are looked up.
If windows-gnullvm targets can be built with naked linker, without clang, then perhaps they should change the default linker and linker flavor to ld.lld?
Are windows-gnullvm targets stable enough for it to be considered a breaking change?
Also, in self-contained mode we are supposed to use ld.lld from the self-contained directory, not rust-lld.
It seems like the logic below results in that, but then the comment above is misleading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If windows-gnullvm targets can be built with naked linker, without clang
Basically all the targets can be linked with just a linker without CC driver given you provide required objects and libraries.
Currently, Rust ships those libraries and objects for *-pc-windows-gnu (in rust-mingw component) and some musl targets (I don't know which ones exactly; definitely x86_64 and aarch64). Which means they could just pass those shipped libs to the linker directly if they are using them anyway (so we are using -Clink-self-contained).
For example, take x86_64-pc-windows-gnu. It ships x86_64-w64-mingw32-gcc.exe and ld.exe, but it doesn't really matter whether we call x86_64-w64-mingw32-gcc -l[rust objects] -l[mingw-w64 objects and libs] -o result.exe or ld -l[rust objects] -l[mingw-w64 objects and libs] -o result.exe as long as you add the flags in the correct form, i.e. prepend them with -Wl, when using GCC as the proxy. It was just easier to ship GCC binary and reuse the code.
What I'm trying to achieve here is to pass the libraries directly to LLD in self-contained-mode for windows-gnullvm hosts, so it can run similarly to windows-gnu hosts even when there is no mingw-w64 toolchain installed. But also keep the previous behaviour, which will call x86_64-w64-mingw32-clang from PATH if it finds one.
Shipping clang is difficult because of its sheer size, so writing a wrapper that just calls LLD would be more feasible.
then perhaps they should change the default linker and linker flavor to
ld.lld?
This would be a groundbreaking change. That would mean it no longer uses user's toolchain and libraries. I think this would be pretty bad.
Also, in self-contained mode we are supposed to use ld.lld from the self-contained directory, not rust-lld.
There are no self-contained binaries, only lib/rustlib/x86_64-pc-windows-gnullvm/bin/gcc-ld/ which contains various wrappers over rust-lld.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no self-contained binaries, only
lib/rustlib/x86_64-pc-windows-gnullvm/bin/gcc-ld/which contains various wrappers over rust-lld.
Hmm, I thought they were already moved, they should be moved eventually anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the musl situation is pretty similar to windows-gnullvm.
Musl targets ship all the necessary library self-contained components, and support -Clink-self-contained=yes, but do not ship C compiler, so it still has to come from somewhere.
I suspect -Clink-self-contained=yes -Clinker=rust-lld will also work on musl targets, because the C compiler isn't strictly required (need to check, maybe some bits are missing if nobody tried it in practice).
Perhaps windows-gnullvm targets can use the same scheme for now?
If external clang is available, then -Clink-self-contained=yes it'll just work, otherwise you'll have to add -Clinker=rust-lld/lld/ld.lld or -Clinker-flavor=ld.lld/etc explicitly.
Doesn't look too bad, considering that adding -Clink-self-contained=yes already requires modifying RUSTFLAGS or similar.
Ideally, maybe target.linker/target.linker_flavor should be maps keyed on self-contained mode?
A number of other target options, like link args, are already effectively keyed on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for not responding here, unlike comments in other threads, these two didn't appear until I reloaded the page. I'm working on the reply.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the musl situation is pretty similar to windows-gnullvm.
Indeed, but there is also windows-gnu target that automagically works even without any toolchain present. I suppose #146634 wouldn't be really resolved until windows-gnullvm achieves the same ease of use.
I suspect
-Clink-self-contained=yes -Clinker=rust-lldwill also work on musl targets, because the C compiler isn't strictly required (need to check, maybe some bits are missing if nobody tried it in practice).
As expected, musl can be linked even from Windows (without installing C toolchain) using rust-lld:
$ cargo rustc --target x86_64-unknown-linux-musl -- -C linker=rust-lld --print link-args
Compiling hello v0.1.0 (C:\Users\Mateusz\AppData\Local\Temp\hello)
"rust-lld" "-flavor" "gnu" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\self-contained\\rcrt1.o" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\self-contained\\crti.o" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\self-contained\\crtbeginS.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\rustcrjVTMi\\symbols.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95.0hn8en36v96xwb3pxtfuaekw6.1pf92ub.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95.4zi0zuc3e5807kuuitkrm1hp6.1pf92ub.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95.bth0v2gc9orb1c10u9swxzo20.1pf92ub.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95.cmyh5siroc2drgq92nl1aggss.1pf92ub.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95.d679eiah7rgb0c88dhs2phow2.1pf92ub.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95.ejj5a33vx05qjkiomxh9w3pi3.1pf92ub.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95.633so8zlsqi3o474upohw2vml.1pf92ub.rcgu.o" "--as-needed" "-Bstatic" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libstd-41aed68db6320929.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libpanic_unwind-4bdf01754011de25.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libobject-78de9b4b58319c3f.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libmemchr-7d42fd256ca9b16b.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libaddr2line-bade3d515fdf432c.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libgimli-0d1c62f3a57b1f1d.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libcfg_if-ce119042f44ad7bf.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\librustc_demangle-9cc1afe6fc29ca3b.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libstd_detect-67e48c94909f88ea.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libhashbrown-d1e76ad2465d5d0f.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\librustc_std_workspace_alloc-c50be85be659204e.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libminiz_oxide-e4035dc1596dc912.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libadler2-1ad2df696961e34a.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libunwind-526c8b9064a75bfc.rlib" "-lunwind" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\liblibc-b767c4e796c7d1fc.rlib" "-lc" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\librustc_std_workspace_core-164e461dc8b91b87.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\liballoc-8a769bb083efdeed.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libcore-52b2f7de2b21b91d.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\libcompiler_builtins-b0102340d25581e8.rlib" "-L" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\rustcrjVTMi\\raw-dylibs" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\self-contained" "-L" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib" "-o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\x86_64-unknown-linux-musl\\debug\\deps\\hello-b633afb87221af95" "--gc-sections" "-static" "-pie" "--no-dynamic-linker" "-z" "text" "-z" "relro" "-z" "now" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\self-contained\\crtendS.o" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnullvm\\lib\\rustlib\\x86_64-unknown-linux-musl\\lib\\self-contained\\crtn.o"
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.15s
$ llvm-readelf -Wl target/x86_64-unknown-linux-musl/debug/hello | head -3
Elf file type is DYN (Shared object file)
Entry point 0x18de0
Perhaps windows-gnullvm targets can use the same scheme for now?
I had considered that and haven't ruled that out. So, as the stopgap workaround, we'd only ship the libs and objects in rust-mingw, and the user would have to add linker = "rust-lld" to their .cargo/config.toml. This would already be an improvement, compiler team (via MCP) figures out how to make it better, or give up the idea.
Ideally, maybe
target.linker/target.linker_flavorshould be maps keyed on self-contained mode?
A number of other target options, like link args, are already effectively keyed on it.
Yeah, sounds like a good idea. It'd need an exemption for windows-gnu, but otherwise sounds good.
An open point would be handling of -C link-arg=<arg> because depending on whether cc driver is used, some of the arguments require adding -Wl,. But, with self-contained mode, I wouldn't expect many of such flags being used.
Previously I had though about a new field like self_contained_linker: Option<..>, but this one is better.
Hmm, I thought they were already moved, they should be moved eventually anyway.
Maybe worth opening an issue to keep track of it, or at least start discussions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe worth opening an issue to keep track of it, or at least start discussions?
Yes, there certainly should be a tracking issue for fine-grained self-contained.
The design is already written on some PR or issue related to lld-on-x86_64-linux stabilization.
I'll add it to my TODO list, just maybe not for today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's land the part about shipping the binaries and supporting the link-contained-option first, and then some fix for the default linker problem separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe worth opening an issue to keep track of it, or at least start discussions?
Yes, there certainly should be a tracking issue for fine-grained self-contained. The design is already written on some PR or issue related to lld-on-x86_64-linux stabilization. I'll add it to my TODO list, just maybe not for today.
|
|
||
| // Returns true if linker is located within sysroot | ||
| fn detect_self_contained_mingw(sess: &Session, linker: &Path) -> bool { | ||
| // Assume `-C linker=rust-lld` as self-contained mode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic here pre-dates windows-gnullvm targets, so apparently someone used windows-gnu targets with the naked rust-lld linker, and I see some supports for that in the target specs.
But this PR removes the self-contained mode from windows-gnu + rust-lld mode, what is the reason for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I lost that in one of the refactors of this code.
I happen to know the person who did it: https://github.com/rust-lang/rust/pull/76167/files#diff-862130c0af71054886913befc8084094485fa7d764d95f55644e033e34acd126R1214
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
He is you? :)
The condition just appeared in 770231e without much discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I linked the PR above. I don't recall much from it, but it was based on some other target, perhaps msvc? There were short discussions which happened in another PR, issue, or some other channel.
At least it still works (using Git Bash):
$ PATH=~/.cargo/bin
$ echo $PATH
/c/Users/Mateusz/.cargo/bin
$ cargo +stable-x86_64-pc-windows-gnu rustc -- -C linker=rust-lld --print link-args
Compiling hello v0.1.0 (C:\Users\Mateusz\AppData\Local\Temp\hello)
"rust-lld" "-flavor" "gnu" "--dynamicbase" "--disable-auto-image-base" "-m" "i386pep" "--high-entropy-va" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\self-contained\\crt2.o" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\rustc6zayvo\\symbols.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.2utymz0xmf0rjdojntrxnwxhl.07lv0pp.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.6k3wyvytftwtg5uhfbmyw0q7h.07lv0pp.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.7ui61tfcjpwxt3rr447d9qtxh.07lv0pp.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.93fcxlueqzo1240093as1kc9t.07lv0pp.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.93zqjlhn2s2sg38q08l74xaxa.07lv0pp.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.d5f8xp7512x4zx2jt4zlttk7m.07lv0pp.rcgu.o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.bqn8dovbywb8binymch9d4tm0.07lv0pp.rcgu.o" "-Bstatic" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-eda97603dd98e790.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-54f0db2b8da74408.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libobject-664c143b09a9bb80.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libmemchr-5fee929e38523ed1.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libaddr2line-057dc260707e05f3.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libgimli-9c7b3da54070bf21.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcfg_if-7c27d5a26a9f3213.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libwindows_targets-e78218c0825d389d.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_demangle-2071562e52929051.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd_detect-6dd86666987ccc26.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libhashbrown-18468d58cd5a9849.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_alloc-4bfcf68bee3d0c11.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libminiz_oxide-aa873642d4270c91.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libadler2-aad28720dda5511e.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-35a53cb7c6b9e1e8.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-d89879dfa27b9858.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_core-14598ccc8530df5e.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-b59c84b50c3a3381.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-b566be85b3fb54ac.rlib" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-ea35a735dade4383.rlib" "-Bdynamic" "-lkernel32" "-lkernel32" "-lkernel32" "-lntdll" "-luserenv" "-lws2_32" "-ldbghelp" "-lgcc_eh" "-l:libpthread.a" "-lmsvcrt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmingwex" "-luser32" "-lkernel32" "--nxcompat" "-L" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\self-contained" "-o" "C:\\Users\\Mateusz\\AppData\\Local\\Temp\\hello\\target\\debug\\deps\\hello-127ffa693f85d6f7.exe" "--gc-sections" "C:\\Users\\Mateusz\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.78s
$ target/debug/hello.exe
Hello, world!
BTW, -C linker=ld also works as long as you don't have ld.exe in PATH (so it uses the one from rust-mingw component), although this one probably wasn't intended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although this one probably wasn't intended
Since we already ship ld.exe and cannot unship it, I don't see problems with supporting it in self-contained mode.
(Just need to eventually move it to self-contained dirs etc etc, like all the other stuff.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to clarify that rust-mingw binaries are shipped in self-contained directory (IIRC we worked together on that).
It's just rust-lld and gcc-ld wrappers that are not self-contained:
$ ls ~/.rustup/toolchains/stable-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/
gcc-ld/ libwinpthread-1.dll* rust-objcopy.exe* wasm-component-ld.exe*
libgcc_s_seh-1.dll* rust-lld.exe* self-contained/
$ ls ~/.rustup/toolchains/stable-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/gcc-ld/
ld.lld.exe* ld64.lld.exe* lld-link.exe* wasm-ld.exe*
$ ls ~/.rustup/toolchains/stable-x86_64-pc-windows-gnu/lib/rustlib/x86_64-pc-windows-gnu/bin/self-contained/
dlltool.exe* GCC-WARNING.txt ld.exe* libwinpthread-1.dll* x86_64-w64-mingw32-gcc.exe*
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As usual, wasm people also did something special without ever consulting with maintainers of the general linking infra.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean wasm-component-ld? There is no standalone version of that. It is just an implementation detail of the wasm32-wasip2 and wasm32-wasip3 targets: https://github.com/rust-lang/rust/tree/main/src/tools/wasm-component-ld
| } | ||
|
|
||
| // Returns true if linker is located within sysroot | ||
| fn detect_self_contained_mingw(sess: &Session, linker: &Path) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In any case, it's good to remove the linker parameter from here.
Linker path is never inferred to be "rust-lld" from flavor, so the condition linker == "rust-lld" is true if and only if sess.opts.cg.linker.or(sess.target.linker) == "rust-lld".
It just better to mention this assumption explicitly in a comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sess.target.linker == "rust-lld" won't be the case for existing targets other than MSVC, so we can omit it.
Additionally, we can avoid searching through PATH when sess.opts.cg.linker is set, assuming we don't care about -C linker=ld working without -C link-self-contained as noticed in #147536 (comment)
Perhaps this change is worth splitting out of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps this change is worth splitting out of this PR?
Sure, why not
|
@bors try jobs=dist-aarch64-windows-gnullvm,dist-x86_64-windows-gnullvm |
This comment has been minimized.
This comment has been minimized.
Windows-gnullvm self-contained try-job: dist-aarch64-windows-gnullvm try-job: dist-x86_64-windows-gnullvm
d45c4c0 to
3ad8250
Compare
|
There were two new commits since last review: abb5f3b and d45c4c0. Everything is squashed now. I've tested x86_64 via Wine using: @rustbot ready |
rust-mingw component for *-windows-gnullvm hosts
|
@bors r+ |
Cc #146634